Field of the Invention
The invention relates to a computer-implemented method for computer-aided generation of an executable control program for controlling a control system with an electronic computing unit, wherein the functionality of the control program is at least partially described in a graphical model, and the graphical model includes at least one sub-model with at least one sub-functionality, wherein the graphical model is first translated into model code in a high-level programming language and the model code is subsequently compiled into the control program that is executable on the control system. In addition, the invention also relates to a computer-implemented method for computer-aided translation of a graphical model describing the functionality of a control program into model code in a high-level programming language, wherein the graphical model includes at least one sub-model with at least one sub-functionality.
Description of the Background Art
The previously described computer-implemented methods for generating an executable control program and model code from a graphical model have been established for years in the field of research using control systems, but especially in the technical development of control systems, and are used intensively in the automotive field, in the aerospace industry, and in other technical and industrial application areas as well, for example. The control systems are generally control units, which is to say small computers with an electronic computing unit (ECU), on which a real-time operating system is usually run. Control systems in the form of control units typically have a variety of I/O interfaces through which the control unit is connected with a physical technical process that is to be influenced, from which measured process variables are thus to be acquired, and that is acted upon by the output of control variables. Accordingly, the external interface to the process includes sensors and actuators.
Description of the functionality of control programs with the aid of graphical models has been known. The models are generally described in the form of block diagrams such as are known from system theory. A signal flow between the various blocks of the block diagram is specified here using signal lines, wherein the blocks contain a particular transfer functionality between their inputs and outputs, and the incoming signals are numerically subjected to this functionality. Graphical models of this type frequently comprise sub-models for hierarchical structuring (for the purpose of clarity), which in the case of block diagrams often have, in turn, the appearance of a block in which the sub-functionality of the sub-model is defined at a finer level of granularity using elementary blocks. One example of an established development environment for building block-based mathematical models is Matlab with Simulink from The MathWorks, Inc.
The use of graphical models for describing the functionality of the control program has the particular advantage that the modeling is relatively clear and intuitive. Above all, the subsequent automated translation of the graphical model into code in a high-level programming language—the model code—entails the advantage that error-prone manual programming/conversion of the modeled functionality into a high-level programming language can be eliminated, and content-related adaptations of the functionality of the control program can be made considerably more quickly and tested on the control system. In order to identify the origin—graphical model—of the content of the functionality of the generated code in the high-level programming language, the translated/generated code is referred to as “model code”. This should not be confused with a text description/definition that may exist of the graphical model in a description language of the modeling environment.
Typically, the model code is then compiled (for reasons of efficiency) into an executable program for the computing unit of the control system by a compiler of the high-level programming language. However, it could also be executed on the control system by an interpreter or serve as input for generating a hardware circuit for control (hard-wired or for a field programmable gate array (FPGA)).
The executable control program is then loaded onto the control system, where it is executed—typically in real time—on the electronic computing unit. On the control system, the control program then implements a sampled-data system in the automatic control sense that is connected with the associated physical technical process in a fixed time interval or even using multiple time intervals/sampling times.
It is known in the conventional art that, for sub-models within a higher-level overall graphical model, during translation of the graphical model into model code in a high-level programming language—this is also called the code generation process—the individual sub-models are translated into functions in the high-level programming language. For example, if a graphical model R contains one sub-model V, then it would be possible to generate a comprehensive function r( . . . ) in which the call to the sub-model code function v( . . . ) that represents the sub-functionality of the sub-model takes place. In this implementation, the entire graphical model must be translated anew if, for example, a change is made within the graphical model, regardless of whether it is made inside or outside the sub-model V.
If there are multiple variants V1, V2 for the sub-functionality of the sub-model V, there are various possibilities in the conventional art for managing these variants of the sub-functionality of the sub-model V. What is then at question is where and when the decision for a specific variant of the sub-functionality should be made. This can take place, for example, during the translation of the graphical model—which is to say during the code generation—into the model code in a high-level programming language—the model code then only contains the valid variant of the sub-functionality selected beforehand. To make such a selection there are, for example, setting possibilities in the code generation options as described in U.S. Pat. No. 7,742,903 B2, which is incorporated herein by reference, or as described in the graphical modeling environment Simulink from The Mathworks, Inc.
It is also stated there that it is alternatively also possible for this to not take place until compilation of the model code if the variants of the sub-functionality contained in the graphical model or in the sub-model are surrounded by suitable preprocessor directives so that the choice of one of the possible variants of the sub-functionality can still be made at the time of compilation. The executable control program that then results is only capable of executing the variant of the sub-functionality of the sub-model that was chosen at the time of compilation, however.
In the first alternative described for managing variants of sub-functionalities, the entire code generation process and the compilation must be carried out anew when a variant is changed or when a different variant is chosen; in the second alternative, in contrast, only recompilation is required, although the generated model code as a whole is larger than in the first alternative because it includes all variants.
U.S. Pat. No. 9,250,873, which herein incorporated by reference, is related to inheritance of code generation options across nested sub models.